07-19-05 



02 : 08pm . F rom-HOCANiHARTSON 



720 406 5302 



T-776 P. 008/01 3 F-805 



Serial No. 09/850,183 

Reply to Office Action of June 27, 2005 

RFMARKS/AR QUMENTS 

Prior to this Amendment, claims 1-16, 18. and 19 were pending in the 

"^Tdependent claims 1. 6, 8, and 16 are amended to address ructions under 
35U.SC.§101- 

Claims 1-16, 18, and 19 remain in the application for consideration by the 
Examiner. 

Claim Rejections UndP " as tl.S.C. S101 

in the June 27, 2005 Office Action, claims 1-7 and 8-16 were rejected under 
35 U.3.C. §101 as being directed to non-statutory subject matter. Independent 
claims 1,6,8, and 16 are amended to address this rejection. 

Claim Rejections U nder 35 U.S.C. S103 

in the Office Action of June 27, 2005, claims 1-2. 8 and 18 were rejected 
under 35 U.S.C. §1 03(a) as being unpatentable over U.S. Patent No. 5,014,220 
('McMann") in view of "Understanding Fault-Tolerant Distributed Systems" 
("Cristian". This rejection is traversed based on the following remarks. 

As discussed in Applicants Background, the present invention is addressing 
the problems with prior network modeling techniques that were limited to modeling of 
hardware devices and their failures and repair. The present invention in contrast 
provides for availability modeling of software components or applications in the 
network and typically, integrating such availability modeling of software components 
with the modeling of hardware devices to provide a more accurate availability model 
for a network device or node and the overall network. 

With the most recent Office Action , McMann is presented and used as the 
base or main reference in rejecting all of the claims as being obvious (i.e.. all 
pending claims are rejected based on McMann in view of additional references). 
Applicant believes that McMann teaches the more standard modeling technique that 
Applicant discusses in its Background and hence. McMann is not effective as 
providing a base reference for rejecting the pending claims. 

More specifically, McMann teaches a hardware-based reliability model 
generator that can build models using user selected hardware components or 
modules. However. McMann provides no teaching of modeling software as a 
component in its reliability models of networks or computer systems. The lack of 
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teaching of modeling software as a component in a network or system can be seen 
a X of McMann with reference to Figure 2. which shows that the mput for the 

::r b u ild er 202 * * — ™ ^ 2 «. 

from col. 8, line 17 to col. 9, line 43, it can be seen that components descnbed ,n 
detai. are only hardware components and no discussion of software apphcafons and 
their failure modes or recover is provided by McMann. Further. McMann in F,gure 
4A shows "a typical computer system which may be represented in the BBD 
(see, McMann beginning at col. 9, line 44). As shown in Figures 4A and 4B and 
described in associated portions of the specification, McMann only teaches modehng 
hardware components (i.e., a system 402. a computer 404, I/O devices 407. a CPU 
406 memory 408, ALU 410. and registers 412). There is not even a suggest-on that 
it would be useful to also model software in the computer 404 as part of the reliability 
model 210 generated by model builder 202. 

Referring now to specific claim language in claim 1. the data structure 
includes "a software availability model' including "an aggregated rate for each of 
said classes of failures for said at least one software component and an 
aggregated repair time for each of said classes of failures for said at least one 
g ^ arf > component " As discussed above. McMann fails to teach that any of the 
components defined and stored in the knowledge bases 214, 216 for inclusion in the 
model 210 is a "software component" as called for in claim 1 . The Office Actoon 
states that McMann teaches the availability models of claim 1 but only discusses 
McMann's teaching of analyzing components of a system, but as will be understood 
from a study of McMann with reference to Figures 2-4B and elsewhere. McMann^s 
••components" are NOT software components. Hence, this key aspect of the 
Applicants' invention is not shown or suggested by McMann. 

Further, the software availability model of the date structure of claim 1 
includes aggregated failure rates for each of a set of classes of failures for a 
software component in a computer platform. More particularly, claim 1 is specrfies 
what types of specific failure classes may be included and modeled with aggregated 
failure rates. The Office Action notes that McMann does not teach these failure 
modes and cites Cristian for teaching the four failure modes in claim 1 . However, 
Cristian fails to overcome the deficiencies of McMann noted above, and particularly, 
fails to teach a software availability model included in a platform availability model 
such that software components are modeled with other components in a model of a 
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network. Hence. the combined teaching of McMann and Cristfan 
claim 1 obvious and wouid not result in the Calmed Invents. Yet further. Cnsfan 
as cited in the Office Action is only discussing hardware failure modes (such as 
server failure). Hence, the combined teaching of these two references fails to 
discuss modeling of software components in a network. As a result. Apphcants 
request that the rejection of claim 1 be withdrawn. 

Yet further the software availability model included aggregated fa.lure rates 
for each of a set of classes of fai.ures of software components. The Examiner ctes 
McMann for teaching the concept of placing fai.ures into classes but at the cKat^n 
McMann discusses "sets of components" but not sets of or classes of M ^ 
hardware components. Hence, there is no teaching here or e.sewhere ,n McMann 
that failures for any component, and particularly, a software component, should be 
placed into a set of classes, that failure rates for each class shou.d be determined 
for each software component in the class, and the rates then aggregated as called 
for in claim 1 . For this additional reason, McMann fails to teach each and every 

limitation of claim 1. 

Claim 2 depends from claim 1 and is believed allowable at least for the 
reasons for allowing claim 1 . However. McMann fails to teach the software 
availability model as discussed with reference to claim 1 . and further, there » no 
teaching in McMann that the platform parameters Hofinr, platform , problems causmq 

,nd lectin — ti "* s tn thP platform P rob ' ems - Furth6r ' 

McMann does not teach that "at least a portion of the platform parameters are used 
to determine the aggregated repair time" that would include repair of the at least one 
software component with McMann not teaching the determination of such an 
aggregate repair time including repair of a software component nor using platform 
parameters to determine it. The Office Action cites recovery and other act,ons 
related to the McMann "components" but as discussed with reference to cla»m 1. the 
McMann components are hardware components and not software components. 
Hence. McMann fails to teach each element of claim 2. and the rejection should be 
withdrawn. 

Independent claims 8 and 18. as with claim 1. are directed to modeling a 
network that includes modeling software components. McMann fails to teach 
modeling of software components but. instead, only discusses hardware 
components in its reliability model. Cristian does not overcome this problem of 
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busses failure modes of servers. Hence, the combination of these 
ZZZ l^l fining failure rates and recovery rates for a software 

r ecoverab.e error state parameters for a software component and then, as o^ed for 

claim 8. generating an ability mode, that indudes such 
the software component. For these reasons. Applicants request that the re.ect.on 
claims 8 and 18 based on these two references be withdrawn. 

Additionally, in the Office Action, claim 3 was rejected under 35 U.S.C. 
9 1 03(a) as being unpatentable over McMann in view of Cristian further in v,ew of 
U S Patent No. 4,870,575 ("Rutenberg"). Claim 3 depends from claim 1 and . 
be ,ieved allowable as depending from an al.owab.e claim, and Rutenberg fails to 
overcome the deficiencies of McMann and Cristian as discussed in reference to 

C ' a,m Claim 4 was rejected under 35 U.S.C. §l03(a) as being unpatentable over 
McMann in view of Cristian further in view of "Survey of Software Tools for 
Evaluating Reliability, Availability, and Serviceability" ("Ma.ek"). Claim 4 depends 
from and is believed allowable as depending from an allowable claim, and Malek 
fails to overcome the deficiencies of McMann and Cristian as discussed .n reference 

to claim 1 . . , 

Claim 5 was rejected under 35.U.S.C. §l03(a) as being unpatentable over 
McMann in view of Cristian further in view of "Availability analysis of a certain class 
of distributed computer systems under the influence of hardware and software 
faults" ("Hassapis-). Claim 4 depends from and is believed allowable as depend.ng 
from an allowable claim, and Hassapis falls to overcome the deficiencies of McMann 
and Cristian as discussed in reference to claim 1. 

,n the Office Action, independent claims 6 and 7 were rejected under 35 
U.S.C §1 03(a) as being unpatentable over McMann in view of Hassapis. This 
rejection is traversed based on the following remarks. 

independent claim 6 calls for a "software availability model" that models repair 
time "for each software component." As discussed with reference to claim 1 . 
McMann fails to teach a "software" availability model but instead teaches only a 
hardware-based model. Hassapis fails to teach in its availability analysis on page 
525 a software availability model that includes "an aggregated failure rate" for each 
software component on a node. Further, Hassapis does not teach that its analysis 
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use, "aggregated repair time" for each software component on a node but instead 
shows use in a stochastic process -or if a computer modu.e is under repa.r at a 
particular time and "1" if the computer modu.e is functioning at that time. For these 
reasons the combination of McMann and Hassapis fails to teach or suggest each 
nation of Cairn 6. Cairn 7 depends from claim 6 and is believed a.lowable as 
depending from an allowable base claim. 

in the Office Action, claims 9-15 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over McMann in view of Cristian further in view of Malek. C.a.ms 
9-12 depend from claim 8 and are believed allowable as depending from an 
allowable base Cairn. Further, Malek fails to overcome the deficiencies of McMann 
and Cristian discussed with reference to claim 8. 

in the Office Action, claims 16 and 19 were rejected under 35 U.S.C. §103(a) 
as being unpatentable over McMann in view of Malek. This rejection is traversed 

based on the following remarks. 

As discussed with reference to claim 1 . McMann fails to teach modeling of a 
software components, and thus, with reference to claim 16, McMann fails to discuss 
any of the steps that describe processing information regarding "a software error 
within a network model (i.e., McMann fails to show determining a recoverable state 
for a software error, a failure rate for a software error, and a recovery rate for a 
software error as called for in claim 16>. Malek does not overcome this deficiency of 
McMann and hence, the combination does not teach claim 16. 

Further, the Office Action cites Malek as teaching determining a fraction of 
recovery failures for warm and non-warm recoveries for the software error with its 
mean time to repair (MTTR) calculation. However, a mean time to repair defines, 
generally, the time to repair or overcome a problem. The Malek MTTR does not 
teach a fraction of failures" from recovery, i.e., a fraction of times that recovery .s 
not successful. Hence, nowhere in Malek is a value of "a number of failures to 
recover from said error discussed, and such a value is not part of the MTTR. The 
Examiner construes "Pdiag" as teaching this concept as this variable is addressing 
the probability the diagnostics will be effective, but Applicants could find no 
indication that such a probability is calculated in the same fashion as the fraction of 
recovery is defined in claim 16. Further, the Pdiag is not incorporated in a 
"recoverable state" for a software error but is Instead used to determine the MTTR. 
For this additional reason, claim 16 is believed allowable over Malek. 
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Cairn 19 >. directed » a compute, program product with tiroes similar to 

applicable to claim 1 9. 

e2D ^ of at,ofm e a bo v e .App. i can, re< ,u e s«t h a,a, lm eW N o,iceo. 

associated «h mis submittal may t. charged to Deposit Account No 8C1 123. 

Respectfully submitted. 
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